Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-012.txt

Text File | 1992-11-18 | 51.1 KB | 1,367 lines | [TEXT/MPS ]

C.S.M.P. Digest             Mon, 09 Mar 92       Volume 1 : Issue 12

Today's Topics:

    Playing 'snd' resources.
    Help with Drag and Drop...
    Can I do these things from a completion proc?
    'snd' resources
    Reading MacApp.$TECH on ETO #5??
    where Hunk Manager?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Patrick John Calahan)
Subject: Playing 'snd' resources.
Date: 29 Jan 92 10:39:06 GMT
Organization: Reed College, Portland, OR

I'm programming in THINK C and I need to play sound resources in the
background.  I'm a bit of a novice in dealing with the toolbox, but my
understanding is that I need to open a sound channel with NewSndChannel
and then call SndPlay.  This seems to work ok the first time the sound is
played, but subsequent sounds will not be played, and it seems to disable
System beeps as well, even after I am done with the application.  Calling
DisposeSndChannel right after the SndPlay remedies this problem, but then
program execution halts until the sound is done playing (which can't
happen for my purposes).  Is there something I need to do after a call to
SndPlay to prepare the channel for the next sound to be played?
    I would be deeply indebted to anyone who could deliver me from
ignorance as to how I can play sounds in the sound buffer without halting
program execution.
                -Patrick Calahan



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Playing 'snd' resources.
Organization: Kalamazoo College
Date: Wed, 29 Jan 1992 13:58:29 GMT

[e-mail] (Patrick John Calahan) writes:
>I'm programming in THINK C and I need to play sound resources in the
>background. ...[Calling SndPlay] seems to work ok the first time the sound is
>played, but subsequent sounds will not be played, and it seems to disable
>System beeps as well, even after I am done with the application.  Calling
>DisposeSndChannel right after the SndPlay remedies this problem, but then
>program execution halts until the sound is done playing (which can't
>happen for my purposes).

You should SndDisposeChannel for every time you SndNewChannel.  That's
why sounds stop working even after you exit your application--there's
still a channel active that you hadn't disposed.  (There was a patch to
_ExitToShell in 6.0.4, I believe, that automatically disposed of
undisposed channels, but it was buggy and they removed it.  Anyone know
if it was revived later?)

OK, so you need to dispose of that channel.  You can't do it right after
you call SndPlay, because either (a) you pass TRUE for the quietNow
parameter, and the sound shuts off immediately, or (b) you pass FALSE
in quietNow, and your program waits until the sound is done.  You have
to do it sometime before you play the next sound.  You _could_ keep a
global for the sound channel, then every time you want to play a sound,
you check to see if it's allocated:  if so, dispose of it immediately,
re-initialize it, and call SndPlay;  if not, initialize it and call
SndPlay.  Be sure to dispose of it before the program ends.

...or, you could use some code that I've written.  It's a THINK C object
to play sounds, you don't need the Think Class Library to use it, it's
pretty flexible, and it does what you want it to do with one call.
(That is, play sounds asynchronously.)  Anyone who wants it can have it.
Just mail me.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Matthew Hall)
Subject:  Playing 'snd' resources.
Date: 29 Jan 92 21:30:50 GMT
Organization: Oberlin College Computer Science


- Another way to implement this is to define a callback routine.  You
pass the proc pointer when you open the sound channel.  Then play the
sound with SndPlay, buffercmd, or notecmd.  Immediately after calling
one of those commands, send a callbackcmd with SndDoCommand (don't use
SndDoImmediate or you're callback routine will be called immediately)
And go on with the rest of your program.
    Then, when your sound is done playing, your callback routine
will be called.  Since it may be called at interrupt time, you can not
dispose of the channel there, However, you can set a global flag to
indicate that the sound is done. (To acess globals, however, you have
to use SetUpA5 and RestoreA5).  Your callback rouutine could be 3
lines long.  Then, in your main loop you could poll the flag, and if
it is set, call SndDisposeChannel.

-Matt Hall

--

<<[e-mail] OR
<<[e-mail]

This is just a beta version signature



- -------------------------

From: [e-mail] (Paul Potts)
Subject:  Playing 'snd' resources.
Date: 30 Jan 92 15:05:54 GMT
Organization: Advanced Workstation Lab, University of Michigan

In article <[e-mail]> [e-mail] (Matthew Hall) writes:
>
>- Another way to implement this is to define a callback routine.  You
>pass the proc pointer when you open the sound channel.  Then play the
>sound with SndPlay, buffercmd, or notecmd.  Immediately after calling
>one of those commands, send a callbackcmd with SndDoCommand (don't use
>SndDoImmediate or you're callback routine will be called immediately)
>And go on with the rest of your program.

I'm having trouble with this. Nothing that crashes or anything bad like
that, but:

- I have code which installs a sampled sound into a channel and plays
notes with it using the sample as an instrument, passing freqCmds
using SndDoCommand. I have set up a callback routine to tell me when
the sound is done playing.

- My callaback routine is getting called right after the sound starts
playing. That is: I send a freqCmd to the channel followed by a
CallBackCmd. The freqCmd starts playing, but after a very short time
(a tenth of a second or so, while it is still playing asynchronously)
my callback routine gets called.

Will callbacks time the sound properly _only_ when used with noteCmds
(now called freqDurationCmds?)

At the moment, if my DisposeChannel method gets called, I have to use
the sound status in addition to looking at my global. My global (soundDone)
will get set by the callback and it looks like I should be able to
dispose of the channel, but in fact an asynch sound might still be
playing, and the sound gets cut off when I dispose of the channel.
Instead I need to spin a loop looking at the sound channel status until
I'm sure it is not busy, then close the channel. This is bothersome,
and sort of violates the spirit of asynchronous sounds.

Any ideas?

--
         -Paul [e-mail]-
I! Hi'm a mtatng siugnaturei vir*ss. You cann~t reisth elping me  spre]d !



- -------------------------

From: [e-mail] (Stephen McIntosh)
Subject:  Playing 'snd' resources.
Date: 2 Feb 92 23:53:28 GMT
Organization: ACUS Australian Centre for Unisys Software, Sydney

Has anyone tried to open and read samples in an AIFF sound file. I'm using
ThinkC5.0.2. Any code samples would be a lot of help.

Thanks in advance
Stephen McIntosh
ACUS-The Australian Centre for UNISYS software
Phone:    [phone]    | ACSnet:   [e-mail]
Fax:    [phone]    | Internet: [e-mail]
115 Wicks Road        | UUCP:     uunet!munnari!syacus.acus.oz.au!stephenm
North Ryde   NSW   2113 |
AUSTRALIA        |
--
Sincerely
Stephen McIntosh
ACUS-The Australian Centre for UNISYS software
Phone:    [phone]    | ACSnet:   [e-mail]



- -------------------------

From: [e-mail] (Matthew Hall)
Subject:  Playing 'snd' resources.
Date: 4 Feb 92 18:44:11 GMT
Organization: Oberlin College Computer Science


    I have reviewed IMV again, and I believe that the callback
routine fo asynch sounds may only work with buffercmds.  See, the
buffercmd locks the channel while the sound is playing, and reopens it
only slightly before the sound is done playing.  Therefore, any sound
command that you place in the queue with SndDoCommand is not executed
until the sound is finished playing (Note that placing a callbackcmd
in the queue with SndDoImmediate will actually bypass the queue and
call the callback routine right away) However, IMV didn't say that
notecmd freezes the channel, so callback routines are performed as
soon as they are placed in the queue.  (but then, for notecmds one
specifies the duration, so the program should know exactly when it's
finished) And if you need to change the frequency of a sound played
with buffercmd, just send commands with SndDoImmediate.

-matt hall\
--

<<[e-mail] OR
<<[e-mail]

This is just a beta version signature



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Playing 'snd' resources.
Organization: Kalamazoo College
Date: Wed, 5 Feb 1992 15:24:58 GMT

[e-mail] (Matthew Hall) writes:
>    I have reviewed IMV again, and I believe that the callback
>routine fo asynch sounds may only work with buffercmds.
>However, IMV didn't say that
>notecmd freezes the channel, so callback routines are performed as
>soon as they are placed in the queue.  (but then, for notecmds one
>specifies the duration, so the program should know exactly when it's
>finished)

Paul Potts and I were discussing this, and we both came to this
conclusion as well.  For example, "bufferCmd, quietCmd, callBackCmd"
plays the sound asynch, then does the callback;  "noteCmd,
quietCmd, callBackCmd" plays the sound for a fraction of a second, then
cuts it off and does the callback.

If bufferCmd is an exception (as it appears to be), this should be made
clear in IM.  (Gr!)  Could someone from Apple verify that this is the
case?
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Steve Anthony Mariotti)
Subject:  Playing 'snd' resources.
Date: 8 Feb 1992 14:50:27 -0600
Organization: U Texas Dept of Computer Sciences, Austin TX

In article <[e-mail]> [e-mail] (Matthew Hall) writes:
>    I have reviewed IMV again, and I believe that the callback
>routine fo asynch sounds may only work with buffercmds.  See, the
>buffercmd locks the channel while the sound is playing, and reopens it
>only slightly before the sound is done playing.  Therefore, any sound

It's is not a good idea to consult Inside Macintosh Volume 5 in relation
to the Sound Manager.  I found this out the hard way.  The details on the
Sound Manager outlined in IM5 are misleading, inconsistent, and often
totally wrong.  You can get the `real' version of the IM 5 sound manager
chapter from `ftp.apple.com' in the docs directory (I believe).

Either that, or use IM 6 if your Sound Manager is a System 7 sound manager.

After banging my head against the wall for a few days, I finally posted my
sound-manager related queries here on c.s.m.p and was told to look for the
`real' chapter on the Sound Manager on `ftp.apple.com'.  After I got that
chapter, and printed it out, everything has been great.

Steve Mariotti
[e-mail]
[e-mail]




- -------------------------

From: [e-mail] (Jim Reekes)
Subject:  Playing 'snd' resources.
Date: 8 Feb 92 02:10:50 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Jamie R. McCarthy) writes:
>
> [e-mail] (Matthew Hall) writes:
> >    I have reviewed IMV again, and I believe that the callback
> >routine fo asynch sounds may only work with buffercmds.
> >However, IMV didn't say that
> >notecmd freezes the channel, so callback routines are performed as
> >soon as they are placed in the queue.  (but then, for notecmds one
> >specifies the duration, so the program should know exactly when it's
> >finished)
>
> Paul Potts and I were discussing this, and we both came to this
> conclusion as well.  For example, "bufferCmd, quietCmd, callBackCmd"
> plays the sound asynch, then does the callback;  "noteCmd,
> quietCmd, callBackCmd" plays the sound for a fraction of a second, then
> cuts it off and does the callback.
>
> If bufferCmd is an exception (as it appears to be), this should be made
> clear in IM.  (Gr!)  Could someone from Apple verify that this is the
> case?

There are no exceptions to any of the commands appearing before a callBackCmd.
The commands are all processed in order.  All commands stop processing of the
command queue until that command has completed.  The bufferCmd and
freqDurationCmd both cause the channel's queue processing to be "paused"
until that command has finished it's job.  Then the next thing in the
queue is processed.  If you have a freqDurationCmd queued before a
callBackCmd, your callBackProc will be ran *after* the freqDurationCmd
has finished.

If you think that the freqDurationCmd shouldn't have been finished yet, then
there's something about your code and/or sound header that you haven't yet
explained.  I need to see your code to explain what's happening.


NEVER NEVER NEVER read Inside Mac _V_ about the Sound Manager.

ONLY ONLY ONLY read Inside Mac _VI_ about the Sound Manager.

Everybody sing, "NEVER NEVER NEVER read..."


- -----------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | All opinions expressed are mine, and
20525 Mariani Ave. MS: 81-EQ |  do not necessarily represent those
Cupertino, CA 95014          |  of my employer, Apple Computer Inc.



---------------------------

From: [e-mail] (Michael E Larson)
Subject: Help with Drag and Drop...
Date: 31 Jan 92 15:15:28 GMT
Organization: University of Delaware


    I am trying to write a small application that will take a GIF
picture and change the creator type to 'GCon' so that it can be
double clicked and GIF Converter will open it.  Its cousin will change
the Type to 'JPEG' and Creator to 'StPP' for PictureDecompress to open
automatically.  I have the programs written, but I now want to change
them to support "Drag and Drop."  I own IM 1-6 so if some one can guide
me to the right section, or someone who has done this before can give
me a hand.  I am writing with ThinkC 5.0  I have set the SIZE flag in
the SetProhectType menu choice to HighLevelEventsAware and all that
jazz.  I called AEInstall..., etc.  Any help will be greatly
appreciated.
-Mike

**********************************************************************
*   [e-mail]    *  These views may not even          *
*   [e-mail]    *  be those of myself, much less     *
*********************************  those of my educational         *
*      Michael E. Larson        *  institution                       *
**********************************************************************
*   University of Delaware - Department of Electrical Engineering    *
**********************************************************************



- -------------------------

From: [e-mail] (W. John Carlsen)
Subject:  Help with Drag and Drop...
Date: 4 Feb 92 02:28:32 GMT
Organization: GTE Laboratories Inc

In article <[e-mail]>, [e-mail] (Michael E Larson) writes:
>
>     I am trying to write a small application that will take a GIF
> picture and change the creator type to 'GCon' so that it can be
> double clicked and GIF Converter will open it.  Its cousin will change
> the Type to 'JPEG' and Creator to 'StPP' for PictureDecompress to open
> automatically.  ...
>
This won't help you write it, but you may be interested in knowing that your
program has already been written.  "FixCreator Pro" (which I got from
Compuserve) is a drag and drop application which you can configure, even
letting you set up to 5 different type and/or creator changes, depending on
the original type and/or creator, or according to file's name (with wildcards,
like *.gif).

It will process multiple types simultaneously if dragged onto the app together.
You can even toggle files.  If type X, change to Y; if type Y, change to X.
I've configured several copies of the app with different names to deal with
different sets of changes: graphic, programming, etc.

It is "freeware"--ie, no shareware or other charges.

John



- -------------------------

From: [e-mail] (Jon Pugh)
Subject:  Help with Drag and Drop...
Date: 7 Feb 92 21:23:39 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Michael E Larson) writes:
>
I have the programs written, but I now want to change
> them to support "Drag and Drop."  I own IM 1-6 so if some one can guide
> me to the right section, or someone who has done this before can give
> me a hand.
> -Mike

The trick is to simply to include a FREF resource for any file type you want
to  be able to drag and drop.  This is mentioned somewhere in the Finder
section of IM6.  Use **** for any file.  There a couple of special codes
for folders and disks too.

Jon



---------------------------

From: [e-mail] (David Peterson)
Subject: Can I do these things from a completion proc?
Date: 31 Jan 92 07:16:28 GMT
Organization: University of Southern California, Los Angeles, CA



After digging through all the docs we have I've decided to try this one
on the net...

Can I safely do the following from a completion proc registered in an
asynchronous PBControl() call?

1.    Call toolbox routines that _do not_ move/purge memory?
    Such as BlockMove() -- 411 doesn't say that it moves memory...

2.    Call routines that are in a segment other than the one my
    completion proc is in? Or could _LoadSeg blow things up?
Note:    The completion procs are in Main -- I hope this means that they
    are locked and can't move around.

3.a    Safely get at the fields/methods of a locked C++ object derived
    from TObject in MacApp? (by stuffing the object pointer in the
    user data field of the parameter block)
    What I'm doing is:
        theObject->Lock(true);
        pb->userDataPtr = theObject;
        ...
    And the methods are in the same segment as the completion proc.

3.b    Safely get at the fields/methods of a C++ object with no base
    class? (again with the methods in the same segment as the
    completion proc) Aren't such objects allocated as pointers (as
    opposed to handles)?

4.    Make other asynchronous PBControl() calls? The MacTCP docs claim
    that I can make them from the ASR (which is called at interupt),
    but doesn`t condone/condemn the practice in completion procs.

Thanks,
-dave.



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Can I do these things from a completion proc?
Date: 3 Feb 92 02:57:12 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] writes:
>
>After digging through all the docs we have I've decided to try this one
>on the net...
>
>Can I safely do the following from a completion proc registered in an
>asynchronous PBControl() call?
>
>1.    Call toolbox routines that _do not_ move/purge memory?
>    Such as BlockMove() -- 411 doesn't say that it moves memory...

It's safe to call BlockMove(). However, you should carefully consider
any Toolbox or OS calls your make, regardless of whether or not they
are on the "may move memory" list. The Mac OS was written with little
consideration for re-entrancy or for dealing with data stored in
handles at interrupt time. For instance, DetachResource is not listed
as moving or purging memory, but I'd never call it at interrupt time.

>
>2.    Call routines that are in a segment other than the one my
>    completion proc is in? Or could _LoadSeg blow things up?
>Note:    The completion procs are in Main -- I hope this means that they
>    are locked and can't move around.

Do this only if you _know_ that the segment is loaded. If it is, calling
the procedure is just an indirect jump. If the segment is not loaded,
_LoadSeg will load it and move memory.

>
>3.a    Safely get at the fields/methods of a locked C++ object derived
>    from TObject in MacApp? (by stuffing the object pointer in the
>    user data field of the parameter block)
>    What I'm doing is:
>        theObject->Lock(true);
>        pb->userDataPtr = theObject;
>        ...
>    And the methods are in the same segment as the completion proc.

If the object is locked, you should be able to get to its fields. Remember
that this also applies to any data stored in a handle, including any
of the object's fields that may be handles.

>
>3.b    Safely get at the fields/methods of a C++ object with no base
>    class? (again with the methods in the same segment as the
>    completion proc) Aren't such objects allocated as pointers (as
>    opposed to handles)?

Should be OK as long as you know the object is completely created and
initialized. I can imagine a situation where your pointer to the object
is valid, but where the constructor or some CMyObject::Initialize
method is still running.

>
>4.    Make other asynchronous PBControl() calls? The MacTCP docs claim
>    that I can make them from the ASR (which is called at interupt),
>    but doesn`t condone/condemn the practice in completion procs.

I expect that this should be OK. I don't know squat about MacTCP, but I
suspect that at time such a practice might actually be necessary.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Charlie Reiman)
Subject:  Can I do these things from a completion proc?
Date: 3 Feb 92 05:28:52 GMT
Organization: University of Illinois at Urbana

[e-mail] (Keith Rollin) writes:
: In article <[e-mail]> [e-mail] writes:
: >4.    Make other asynchronous PBControl() calls? The MacTCP docs claim
: >    that I can make them from the ASR (which is called at interupt),
: >    but doesn`t condone/condemn the practice in completion procs.
:
: I expect that this should be OK. I don't know squat about MacTCP, but I
: suspect that at time such a practice might actually be necessary.

I can verify that yes, you can do this. In fact, it works quite well,
provided you're using MacTCP 1.1. 1.0.[12] has a bug that doesn't take
well to heavy abuse of this feature. It is an effective means to speed
up TCP receives of large data streams.

--
Charlie Reiman - [e-mail]
Submissions to RHF: 3
Times published in RHF: 4



- -------------------------

From: [e-mail] (Tim Dierks, Cray abuser)
Subject:  Can I do these things from a completion proc?
Date: 3 Feb 92 22:21:35 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (David Peterson) writes:
>
>
>
> After digging through all the docs we have I've decided to try this one
> on the net...
>
> Can I safely do the following from a completion proc registered in an
> asynchronous PBControl() call?
>
> 1.    Call toolbox routines that _do not_ move/purge memory?
>     Such as BlockMove() -- 411 doesn't say that it moves memory...

Yes.... most of them.  For a long time, moves/purges memory was used to mean
"don't call this at interrupt time".  This means that some routines which
didn't move or purge memory, but relied on unlocked handles, etc, were put
into the list.  Check out the new & improved list in the Inside Mac X-Ref,
2nd edition; it has a list which actually says "don't call this from an
interrupt".

> 2.    Call routines that are in a segment other than the one my
>     completion proc is in? Or could _LoadSeg blow things up?
> Note:    The completion procs are in Main -- I hope this means that they
>     are locked and can't move around.

This is OK, as long as (1) Your A5 is valid.  You can't be sure your A5
will be correct when you're called from an interrupt; therefore, you've
got to restore it before trying to go through the jump table.  And (2):
The routine you're calling must be already loaded; you cannot get code
resources off the disk at interrupt time.  You're correct in that routines
in the Main segment are always locked & loaded.

> 3.a    Safely get at the fields/methods of a locked C++ object derived
>     from TObject in MacApp? (by stuffing the object pointer in the
>     user data field of the parameter block)
>     What I'm doing is:
>         theObject->Lock(true);
>         pb->userDataPtr = theObject;
>         ...
>     And the methods are in the same segment as the completion proc.
>
> 3.b    Safely get at the fields/methods of a C++ object with no base
>     class? (again with the methods in the same segment as the
>     completion proc) Aren't such objects allocated as pointers (as
>     opposed to handles)?

I don't know enough about C++ internals to say for sure, but I think
both of these should be OK.  Make sure your A5 is correct, in both
cases, and in (3.a) you shouldn't be calling Lock from the interrupt,
as it makes a call (HLock) which can't be called at interrupt time.

> 4.    Make other asynchronous PBControl() calls? The MacTCP docs claim
>     that I can make them from the ASR (which is called at interupt),
>     but doesn`t condone/condemn the practice in completion procs.

This is OK, and is the basis for most server-based programs; chained
completion routines is the best way to get fast server response.  Note,
however, that they _must_ be asynchronous; a lot of people who ignored
this broke most heinously under VM with System 7.0.

Tim Dierks
MacDTS, but I speak for myself



- -------------------------

From: [e-mail] (Tim Dierks, Cray abuser)
Subject:  Can I do these things from a completion proc?
Date: 3 Feb 92 22:21:55 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (David Peterson) writes:
>
>
>
> After digging through all the docs we have I've decided to try this one
> on the net...
>
> Can I safely do the following from a completion proc registered in an
> asynchronous PBControl() call?
>
> 1.    Call toolbox routines that _do not_ move/purge memory?
>     Such as BlockMove() -- 411 doesn't say that it moves memory...

Yes.... most of them.  For a long time, moves/purges memory was used to mean
"don't call this at interrupt time".  This means that some routines which
didn't move or purge memory, but relied on unlocked handles, etc, were put
into the list.  Check out the new & improved list in the Inside Mac X-Ref,
2nd edition; it has a list which actually says "don't call this from an
interrupt".

> 2.    Call routines that are in a segment other than the one my
>     completion proc is in? Or could _LoadSeg blow things up?
> Note:    The completion procs are in Main -- I hope this means that they
>     are locked and can't move around.

This is OK, as long as (1) Your A5 is valid.  You can't be sure your A5
will be correct when you're called from an interrupt; therefore, you've
got to restore it before trying to go through the jump table.  And (2):
The routine you're calling must be already loaded; you cannot get code
resources off the disk at interrupt time.  You're correct in that routines
in the Main segment are always locked & loaded.

> 3.a    Safely get at the fields/methods of a locked C++ object derived
>     from TObject in MacApp? (by stuffing the object pointer in the
>     user data field of the parameter block)
>     What I'm doing is:
>         theObject->Lock(true);
>         pb->userDataPtr = theObject;
>         ...
>     And the methods are in the same segment as the completion proc.
>
> 3.b    Safely get at the fields/methods of a C++ object with no base
>     class? (again with the methods in the same segment as the
>     completion proc) Aren't such objects allocated as pointers (as
>     opposed to handles)?

I don't know enough about C++ internals to say for sure, but I think
both of these should be OK.  Make sure your A5 is correct, in both
cases, and in (3.a) you shouldn't be calling Lock from the interrupt,
as it makes a call (HLock) which can't be called at interrupt time.

> 4.    Make other asynchronous PBControl() calls? The MacTCP docs claim
>     that I can make them from the ASR (which is called at interupt),
>     but doesn`t condone/condemn the practice in completion procs.

This is OK, and is the basis for most server-based programs; chained
completion routines is the best way to get fast server response.  Note,
however, that they _must_ be asynchronous; a lot of people who ignored
this broke most heinously under VM with System 7.0.

Tim Dierks
MacDTS, but I speak for myself



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Can I do these things from a completion proc?
Date: 4 Feb 92 20:15:28 GMT
Organization: MacDTS Mongols

> In article <[e-mail]>, [e-mail] (David Peterson) writes:
> > 3.a    Safely get at the fields/methods of a locked C++ object derived
> >     from TObject in MacApp? (by stuffing the object pointer in the
> >     user data field of the parameter block)
> >     What I'm doing is:
> >         theObject->Lock(true);
> >         pb->userDataPtr = theObject;
> >         ...
> >     And the methods are in the same segment as the completion proc.

Try to avoid locking handles, instead use temp stack based variables.
Handle locking is more expensive concerning performance and memory use.

> > 3.b    Safely get at the fields/methods of a C++ object with no base
> >     class? (again with the methods in the same segment as the
> >     completion proc) Aren't such objects allocated as pointers (as
> >     opposed to handles)?

Yes, MPW C++ classes which are not inherited from PascalObject or
HandleObject are pointer based. Thus you shouldn't have any
de-referencing problems, but more of performance ones.

Kent Sandvik
DTS slacker



- -------------------------

From: [e-mail] (Larry Rosenstein)
Subject:  Can I do these things from a completion proc?
Date: 4 Feb 92 21:49:39 GMT
Organization: Object Based Systems, Apple Computer, Inc.

In article <[e-mail]> [e-mail] writes:
>
>Can I safely do the following from a completion proc registered in an
>asynchronous PBControl() call?
>
>2.    Call routines that are in a segment other than the one my
>    completion proc is in? Or could _LoadSeg blow things up?

_LoadSeg moves memory, and can't be called.  If you know that _LoadSeg won't
be called then the procedure call is OK.

>3.a    Safely get at the fields/methods of a locked C++ object derived
>    from TObject in MacApp? (by stuffing the object pointer in the
>    user data field of the parameter block)

A TObject descendant is just another handle.  I think locking it is
necessary and sufficient.

>    And the methods are in the same segment as the completion proc.

That's the same as 2.  The dispatching code should be in the Main segment
already, so you know it will be in memory.

>3.b    Safely get at the fields/methods of a C++ object with no base
>    class? (again with the methods in the same segment as the
>    completion proc) Aren't such objects allocated as pointers (as
>    opposed to handles)?

It's probably OK, but you can't be sure.  A class can overload operator new
and allocate the object any place it wants.

--
Larry Rosenstein, Apple Computer, Inc.

[e-mail]
(or AppleLink: Rosenstein1)



- -------------------------

From: [e-mail] (Rick Holzgrafe)
Subject:  Can I do these things from a completion proc?
Date: 4 Feb 92 21:53:27 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (David Peterson) writes:
> Can I safely do the following from a completion proc registered in an
> asynchronous PBControl() call?
> [...]
> 4.    Make other asynchronous PBControl() calls? The MacTCP docs claim
>     that I can make them from the ASR (which is called at interupt),
>     but doesn`t condone/condemn the practice in completion procs.

Yes, if you're careful. Things to watch out for:

* In some cases (I don't know about MacTCP in particular) your completion
routine can be called before your asynchronous PBControl() call returns -
as though you had made the call synchronously. This can happen with ADSP,
for example, when you ask to read data that the driver has already buffered
up for you. So make sure that you're ready for the completion routine to
be called (again) BEFORE you make the next asynchronous PBControl() call.

* This implies that your completion routine can in effect be called
recursively, to some depth or other. Be sure that it is re-entrant (that's
another way of saying what I said in the last point) and try to keep your
stack usage low, because you don't know whose stack you're using
when an async completion routine gets called. I've seen bombs because
some little utility app with a dinky stack happens to be running when an
interrupt comes in.

* If you can't keep your stack usage low, you'll have to pre-allocate some
memory to use as your own stack, and play some VERY messy games to swap
stacks as needed. I don't recommend it, but it can be done.

Hope this helps.

- ---------------------------------------------------
Rick Holzgrafe   [e-mail]   AppleLink HOLZGRAFE1
     {sun,voder,nsc,mtxinu,dual}!apple!rmh
Apple Computer, Inc.
20525 Mariani Ave. MS: 3-PK
Cupertino, CA 95014
     --- My opinions, not Apple's.



- -------------------------

From: [e-mail] (Jim Reekes)
Subject:  Can I do these things from a completion proc?
Date: 8 Feb 92 02:34:25 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Keith Rollin) writes:
>
> In article <[e-mail]> [e-mail] writes:
> >
> >After digging through all the docs we have I've decided to try this one
> >on the net...
> >
> >Can I safely do the following from a completion proc registered in an
> >asynchronous PBControl() call?
> >
> >1.    Call toolbox routines that _do not_ move/purge memory?
> >    Such as BlockMove() -- 411 doesn't say that it moves memory...
>
> It's safe to call BlockMove(). However, you should carefully consider
> any Toolbox or OS calls your make, regardless of whether or not they
> are on the "may move memory" list. The Mac OS was written with little
> consideration for re-entrancy or for dealing with data stored in
> handles at interrupt time. For instance, DetachResource is not listed
> as moving or purging memory, but I'd never call it at interrupt time.

In addition, I have to add an final warning.  This may actually mean that you
cannot call most toolbox traps at interrupt level.

Many of the traps rely upon low memory globals.  The Window Manager does this.
The Process Mgr (aka MultiFinder) will swap application specific low memory
globals with each context switch.  The low memory global WindowList is an
example of this.  It changes with each process that's the current process.
>From an interrupt routine you may be "out of context" so that your application's
globals are not in place.  This means that if your interrupt routine called
FrontWindow() it could get the wrong application's window list.  FrontWindow()
does not move/purge memory but you CANNOT call it within an interrupt routine.

Additionally, which globals are considered "appliation specific" are not
documented because they've changed with different versions of the system.
This means you cannot determine what low memory globals are valid while within
the interrupt.  Also, we've don't have a list of the globals used by all
of the traps so you don't know what traps are really safe.  The only way
to know that would be to have the source code.

Furthermore, you cannot tell exactly when an application is fully in context
from within an interrupt because you may have interrupted the Process Manager
performing the context switch.  Maybe there's a safe way of doing this under
System 7 by finding the current process, but I'm not %100 sure.  Testing
CurApp is not good enough.

This little known tid bit has bitten a few applications.  Tell a friend.

An interrupt routine shouldn't do much more that set a flag for the event
loop.  There are some documented traps that you can call from an interrupt
routine but I try to avoid doing much of anything other than setting a flag.
Even calling the File System asynchronously is allowed, but it's not a good
idea.  The problem with that one is that the SCSI Manager is NOT asynchronous
and will cause the File System to hang at the interrupt routine waiting for
the SCSI transfer to complete.  This causes the user's machine to be hung
during the time for the transfer and you shouldn't do this at interrupt level.

- -----------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | All opinions expressed are mine, and
20525 Mariani Ave. MS: 81-EQ |  do not necessarily represent those
Cupertino, CA 95014          |  of my employer, Apple Computer Inc.



---------------------------

From: [e-mail] (Patrick John Calahan)
Subject: 'snd' resources
Date: 3 Feb 92 21:14:12 GMT
Organization: Reed College, Portland, OR

How can I call SndDisposeChannel once a sound has finished playing?

I'm still wallowing in my programming impotence.  I still can't get
SndPlay to do play 'snd's asynchronously.
Whenever I call SndDisposeChannel, the machine crashes (unless I call it
right after the SndPlay, but this is no good since SndDispose waits for
the sound to finish playing).  I tried using callBackCmd to no avail.  I
imagine i'm missing something stupid/syntactical? I dunno.  If anyone has
any simple code examples to offer, it would be much appreciated.

    Sorry to beat a dying horse,
            -Pat



- -------------------------

From: [e-mail] (David M Marcovitz)
Subject:  'snd' resources
Date: 3 Feb 92 22:48:39 GMT
Organization: University of Illinois at Urbana

I tried sending this by email to Patrick Calahan
([e-mail]), but it kept bouncing so here it is for all
to see.

- ---

OK, here's something that you might try.  It relies on the fact that
you want to play the sound asynchronously, BUT you only want to play
one sound at a time.  If you try to play two sounds simultaneously,
the second sound won't start until the first one finishes.  However,
if you try to play a sound and write stuff all over the screen, they
will happen at about the same time.  I hope this helps.

This was written in Think C 5.0.2 for use with TCL, but I am modifying
it just to show you the important stuff.  Let me know if you have any
questions.  This basic idea works for me.  I hope it works for you,
too.

- -----------------

static    SndChannelPtr    theChannel = NULL; /* declare and initialize the
                        the static var */

void    PlaySound(StringPtr aSoundName)
{
    Handle            sndHandle;
    OSErr            theErr;

    if (theChannel != NULL)
    {
        SndDisposeChannel(theChannel, FALSE);
        theChannel = NULL;
    }

    SndNewChannel(&theChannel, 5, initMono, NULL);

    sndHandle = GetNamedResource('snd ', aSoundName);
    HLock(sndHandle); /* I don't think this locking is necessary. */
    LoadResource(sndHandle);
    theErr = ResError(); /* I should probably do something with this
                error, but I just look at it in the debugger */
    theErr = SndPlay(theChannel, sndHandle, TRUE);
    HUnlock(sndHandle);
    ReleaseResource(sndHandle);
}



--
David M. Marcovitz                     |  internet: [e-mail]
Computer-based Education Research Lab  |            [e-mail]
University of Illinois                 |  novanet:  marco / cca / nova



- -------------------------

From: [e-mail] (Jim Reekes)
Subject:  'snd' resources
Date: 8 Feb 92 02:15:13 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (David M Marcovitz) writes:
>
> I tried sending this by email to Patrick Calahan
> ([e-mail]), but it kept bouncing so here it is for all
> to see.
>
> -----
>
> OK, here's something that you might try.  It relies on the fact that
> you want to play the sound asynchronously, BUT you only want to play
> one sound at a time.  If you try to play two sounds simultaneously,
> the second sound won't start until the first one finishes.  However,
> if you try to play a sound and write stuff all over the screen, they
> will happen at about the same time.  I hope this helps.
>
> This was written in Think C 5.0.2 for use with TCL, but I am modifying
> it just to show you the important stuff.  Let me know if you have any
> questions.  This basic idea works for me.  I hope it works for you,
> too.
>
> -------------------
>
> static    SndChannelPtr    theChannel = NULL; /* declare and initialize the
>                         the static var */
>
> void    PlaySound(StringPtr aSoundName)
> {
>     Handle            sndHandle;
>     OSErr            theErr;
>
>     if (theChannel != NULL)
>     {
>         SndDisposeChannel(theChannel, FALSE);
>         theChannel = NULL;
>     }
>
>     SndNewChannel(&theChannel, 5, initMono, NULL);
>
>     sndHandle = GetNamedResource('snd ', aSoundName);
>     HLock(sndHandle); /* I don't think this locking is necessary. */
>     LoadResource(sndHandle);
>     theErr = ResError(); /* I should probably do something with this
>                 error, but I just look at it in the debugger */
>     theErr = SndPlay(theChannel, sndHandle, TRUE);
>     HUnlock(sndHandle);
>     ReleaseResource(sndHandle);
> }


This will crash under any system older than 6.0.7.  The problem is in
your call to SndNewChannel.  You should pass 0 as the snth ID.

This will crash under *ALL* versions of the Sound Manager because you've
called SndPlay asynchronously but have unlocked and disposed of the
snd resource.  This is bad because the data has to remain locked and
resident until the sound has completed.

You can read about how to properly write Sound Manager code by reading
through SoundApp.  It's official sample code from Apple, and is available
on the FTP sites.


- -----------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | All opinions expressed are mine, and
20525 Mariani Ave. MS: 81-EQ |  do not necessarily represent those
Cupertino, CA 95014          |  of my employer, Apple Computer Inc.



---------------------------

From: [e-mail] (Blair M. Burtan)
Subject: Reading MacApp.$TECH on ETO #5??
Date: 3 Feb 92 23:11:50 GMT
Organization: Boston U. College of Engineering

A question for ETO users out there.  What is the application for reading
the MacApp.$Tech archives on the ETO CD?
--
+---------------------------------------+
+ "If it isn't Baroque, don't fix it."  +
+               - Beauty and The Beast  +
+                        +
+ Blair M. Burtan: [e-mail]    +
+                  [e-mail]   +
+---------------------------------------+



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Reading MacApp.$TECH on ETO #5??
Date: 5 Feb 92 00:05:25 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Blair M. Burtan) writes:
>
> A question for ETO users out there.  What is the application for reading
> the MacApp.$Tech archives on the ETO CD?

Those files are AppleLink files, i.e. TEXT format. Any editor
or word processor should work.

Kent Sandvik



- -------------------------

From: [e-mail] (Keith R. Fieldhouse)
Subject:  Reading MacApp.$TECH on ETO #5??
Date: 5 Feb 92 14:19:15 GMT
Organization: Rensselaer Polytechnic Institute, Troy NY



I've been able to read the individual files with AppleLink.  What I'd like,
though is a browser that allows me to look at the subjects and choose the
files that I want to read (a browser other than the Finder that is :-))
Can AppleLink be configured to do that?

                - Keith

--
Keith R. Fieldhouse            [e-mail]        "READY?"



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Reading MacApp.$TECH on ETO #5??
Date: 7 Feb 92 20:18:08 GMT
Organization: MacDTS Mongols

In article <_w=[e-mail]>, [e-mail] (Keith R. Fieldhouse) writes:
>
>
>
> I've been able to read the individual files with AppleLink.  What I'd like,
> though is a browser that allows me to look at the subjects and choose the
> files that I want to read (a browser other than the Finder that is :-))
> Can AppleLink be configured to do that?

Nope, someone tried to write a similar thread-based text browser tuned for
MacApp entries some ago (was it called Threesaver?), anyway I have not
heard anything about the project for a long time.

Anyway, there might be a need for a PD text browser which could browse
general text based on particular pattern recognition criterias, it
could be useful for comp.sys.mac.programmer archives as well. I've used
elm for opening mbox type UNIX News archives, and it shouldn't be that
hard to write a hardcoded Mac browser, but to make it more smart requires
more design, and maybe agent-AI type capabilities.

Kent Sandvik



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Reading MacApp.$TECH on ETO #5??
Date: 7 Feb 92 20:19:20 GMT
Organization: MacDTS Mongols

In article <_w=[e-mail]>, [e-mail] (Keith R. Fieldhouse) writes:
>
>
>
> I've been able to read the individual files with AppleLink.  What I'd like,
> though is a browser that allows me to look at the subjects and choose the
> files that I want to read (a browser other than the Finder that is :-))
> Can AppleLink be configured to do that?

Another suggestion, we are using On Location for indexing source and
information servers/hard disks, so if you index the CD with On Location
you should have a pretty good way to access MacAppTech archives.

Kent Sandvik



---------------------------

From: [e-mail] (Jane Eisenstein)
Subject: where Hunk Manager?
Date: 5 Feb 92 23:33:21 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

I'm interested in getting product info on the Hunk Manager.  Can someone
supply me with a phone number or company name and address?

Is anyone happily using this product?

    Jane Eisenstein
    [e-mail]



- -------------------------

From: [e-mail] (Ben Haller)
Subject:  where Hunk Manager?
Date: 8 Feb 1992 00:18:24 GMT
Organization: Stick Software

In article <[e-mail]> [e-mail]
   (Jane Eisenstein) writes:
>I'm interested in getting product info on the Hunk Manager.  Can someone
>supply me with a phone number or company name and address?
>
>Is anyone happily using this product?
>
>    Jane Eisenstein
>    [e-mail]

  I thought they had changed this to the SO Manager, in order to not be
sexist?  I think it's prerelease, their beta testers are having a lot of
trouble with compatability problems.  Once they get it out the door,
though, it should make Macs a lot more popular, no?
  As to whether anyone is happily using the product, well, I can't say
I've had much success, but I know people who have had other experiences...
I think it basically depends on what kind of platform you're running the
manager on.
  As with everything else in the OS, people are already complaining that
you need to go around the manager to obtain sufficient speed...and your
development system had better have the right glue...I'm running low on
jokes for now, anyone else wanna join the fun?
  (The original post *was* a joke, wasn't it?)

-Ben Haller ([e-mail])



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  where Hunk Manager?
Organization: Kalamazoo College
Date: Sat, 8 Feb 1992 19:43:28 GMT

[e-mail] (Ben Haller) writes:
>[e-mail] (Jane Eisenstein) writes:
>>I'm interested in getting product info on the Hunk Manager.  Can someone
>>supply me with a phone number...?
>>
>  As to whether anyone is happily using the product, well, I can't say
>I've had much success, but I know people who have had other experiences...
>I think it basically depends on what kind of platform you're running the
>manager on.
>  As with everything else in the OS, people are already complaining that
>you need to go around the manager to obtain sufficient speed...and your
>development system had better have the right glue...

I heard it's not 32-bit clean.  This means, of course, that if you don't
strip off the important bits, you could end up entering the routine in
completely the wrong place.

Plus, it's very object-oriented.  I may be old-fashioned, but I prefer
the good old days, when no one walked around saying "OOPS" all the time.
Now all anyone wants to do is lock up your main segment.

There's going to be a new group of apple events to deal with it.  Last I
heard, they were going to call it the "sticky suite."
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Russell S. Finn)
Subject:  where Hunk Manager?
Date: 9 Feb 92 20:45:47 GMT
Organization: /u/rsfinn/.organization

Ben Haller and Jamie McCarthy obviously thought this was a joke, which
I guess is understandable, but they didn't put any smileys in their
posts either, which might confuse some people too.

In fact, it's *not* a joke.  For the original poster, Jane Eisenstein,
and anyone else who's interested, here's some information I found
elsewhere.  Note that I have *not* used this product, so I can't
discuss its merits (but it sure *sounds* like a good idea).

"The Hunk Manager is a database tool designed for use with Apple
Macintosh computers. It is a replacement for the Resource Manager,
the simple and incredibly useful database built into the Macintosh
Toolbox.  It provides a library of routines which are the analogues of
those used in the Resource Manager, but without the limitations
imposed by the Resource Manager architecture."

...

"The Macintosh programming environment is based on handles
(relocatable blocks of program defined memory), and The Hunk Manager
was designed explicitly to work with variable length, handle-based
structures.  Almost any kind of Macintosh data can be stored and
manipulated almost transparently using The Hunk Manager.

"If you've used the Resource Manager you already know how to use the
Hunk Manager.  The Hunk Manager routines provide almost 'plug-and-
play' compatibility with Resource Manager calls.  The Hunk Manager is
available as a linkable object file library for MPW C/Pascal and Think
C/Pascal."

Here's the contact information:

Gettys Group Software Inc.
401 East Illinois Street, Suite 600
Chicago, IL  60611
Fax [phone]
312.836.4222
AppleLink: GG.SOFT

I am not affiliated with this company, just passing the info along.

-- Russell S. Finn
[e-mail]



---------------------------

End of C.S.M.P. Digest
**********************